今天這篇純屬雜談，也算是自己在維護專案過程中遇到的狀況。

一個專案營運久了，自然會進入維護期，可能有新的需求進來、規格的調整、功能棄用…各種狀況。通常比較麻煩的情況會是新規格和舊規格需要共存的狀況。舊規格之所以會需要保留是避免有一些舊功能因為導入了新的規格之後就壞掉了，一般來說專案 unit test 寫得很完善的話其實很容易提前發現問題，但如果沒有的話…就可能就會是一顆不定時炸彈。

隨便一個例子，假如會員資料的手機號碼要改成支援國碼 (+886) 的格式，可能系統發送簡訊的功能就會因此受到影響。假如你剛接手一個專案，還不熟悉系統會如何使用這個資料欄位，你會很放心地把它改掉嗎？如果還不確定造成的影響是什麼？短期內可以沒辦法很詳細地排查完畢，那可能就會需要暫時採用新舊規格共存的方式

大致敘述一下思路：

舊規格是原本系統使用的，資料欄位為 X，新規格是因應新需求而誕生的，資料欄位為 Y。

系統內原本的功能一樣維持使用 X 欄位，新功能則是使用的 Y 欄位。
既有的程式碼因為使用 X 欄位，所以不需要調整。

接下來是 X 欄位過渡到 Y 欄位的過程：

改版初期，Y 欄位的資料可以從 X 欄位轉換過去 (透過程式批次執行更新指令)。如果沒辦法順利轉換的話，Y 欄位就先保持 NULL 空值或是預設值。假如是必填或是無法重複 (UNIQUE) 的狀況，可能會需要先暫時讓該欄位可以接受 NULL，並且在使用者下次登入系統時將使用者導頁至會員更新資料頁面。

使用者頁面要顯示 X 欄位還是 Y 欄位？

假如未來系統走向是以 Y 欄位資料為主，而且預劃要淘汰 X 欄位的話，可以優先顯示 Y 欄位， X 排第二序位。需要注意的是，目前的使用者頁面需要能夠顯示 X 欄位和 Y 欄位的資料，這邊會有一點小複雜。使用者在更新資料的時候仍然是需要分別在 X 欄位和 Y 欄位寫入資料，這樣舊功能還是能夠維持正常運作。隨著時間推移，系統中大部分的使用者應該都更新成有 Y 欄位的狀態了。

再來就是找到系統中還有在使用 X 欄位的舊功能，把它改成可以讀取 Y 欄位。然後等到系統中的 X 欄位完全不會被使用的時候，就可以放心地讓 X 欄位退場了。

最後的小統整和比較：

• X 欄位，舊功能使用，更新資料時會寫入舊格式，在使用者頁面中第二順序顯示 (真的沒有 Y 才會顯示)
• Y 欄位，新功能使用，更新資料時會寫入新格式，在使用者頁面中優先顯示 (蓋掉 X 的值)

以上小小分享，祝大家維護專案都順順利利 (,,・ω・,,)